The X-Philes (2nd Revision)/The X-Philes Number 1 (1995).iso/xphiles/hp48_2/hackit/comp.sys.handhelds_5623_000000.msg

Internet Message Format | 1995-03-31 | 14KB

Path: en.ecn.purdue.edu!noose.ecn.purdue.edu!news.cs.indiana.edu!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!helios!tamsun.tamu.edu!ftg0673
From: [e-mail] (Rick Grevelle)
Newsgroups: comp.sys.handhelds
Subject: HP48 HACKIT Library
Message-ID: <[e-mail]>
Date: 6 Apr 91 07:00:46 GMT
Sender: [e-mail]
Organization: Texas A&M University
Lines: 270

HACKIT is a library of utilities designed to facilitate hacking in the HP48SX.
While a few of these routines actually have origins that can be traced back to
the HP28S, the majority of them are relatively new.  Prototypes to several of
the routines have been extensively beta tested, and consequently is reflected
in the material appearing here.

A majority of these routines were written in SYSTEM RPL type fashion utilizing
almost exclusively prefixed machine code to accomplish their intended results.
Very little preexisting SYSTEM RPL has been utilized, and there are a few cases
in which an existing prefixed machine routine could have been used in place of
user written machine code, but was not.  There are multiple reasons for having
done this, however the primary concern was usually to minimize execution times
rather than reduce memory consumption.

There are a few individuals whose contributions and generousities have greatly
affected this material, and who deserve to be recognized for their part.  I'd
first like to thank Jake Schwartz for all of his ideas and countless hours of
collaboration.  Equally important, thanks to Jan Brittenson for his technical
support and detailed explanations of the 48's machine code.  Thanks to Robert
Ellis for his hardware expertise and patience.  Also Jim Cloos for furnishing
his CRC algorithm.  Last, Alonzo Gariepy, for without his help, none of these
programs would have ever been possible in the first place.


Rick Grevelle


                HACKIT

==============================================================================


Both of the machine routine algorithms found in these first two programs were
originally used in similar schemes written for the 28S.  Neither algorithm is
mine, and were in fact used by HP in the 28.  More recently they were utilized
in the encoding schemes ->ASC, and ASC-> written by Wickes, who very well may
have conceived them, considering the fact that he already has a great deal of
code to his credit


                ->ASCI

This is a generalized binary-to-ascii conversion scheme that returns a string
of hexadecimal characters which are the equivalent internal representation of
the argument.  When the SYSTEM FLAG -28 is set, both the prolog and the length
of code objects are truncated, meaning that the result string contains in-line
machine code only.  When this flag is clear, which is the default, truncation
does not occur.  All other object types are unaffected by the flag setting.

                ASCI->

Reversing the result of the previous routine is made possible with this scheme
which converts ascii-to-binary, taking as its argument a string of hexadecimal
characters. When SYSTEM FLAG -29 is set, strings are treated as in-line machine
code, whereby a code object would be the result.  When flag -29 is clear one of
two things happens depending on the string argument itself, and is explained in
the following summary.



                IMPORTANT POINTS

i)   The above routines were intended to provide a means for *toggling* stack
     objects back between their internal string representation and immediately
     executable form, which means ROM objects must be dealt with differently.
     An important attribute associated with these two schemes is their ability
     to differentiate between ROM and RAM objects.

ii)  When an argument taken by the ->ASCI routine is a ROM object, a character
     string representing the five nibble address where that object is located
     in ROM is returned.  Strings containing only five characters that are used
     as arguments for ASCI-> are treated as pointers; solitary prologs are not
     permitted though.

iii) Spaces and newline carriage returns are allowed in strings that are to be
     converted by ASCI->.  This helps to alleviate some of the confusion when
     looking at long strings of hexadecimal characters in that spaces can now
     be used to separate groups of characters, and newline carriage returns to
     segment the string into several lines when editing.

iv)  Any object encoded using ->ASC can be unencoded using ASCI->.  There's no
     longer a need for these silly schemes to delete newline carriage returns,
     or calculate a new checksum to tack on the of an ->ASC encoded object that
     has been altered in order to get ASC-> to work.  ->ASC, and ASC-> were an
     effort to provide a safe means of transferring data, and not for hacking.

v)   ASCI-> performs equally well on strings of odd number lengths because the
     RPL segments of the program correctly utilize the block allocate routine
     at #61C1Ch.



                SCRC

Calculates the checksum on a string of hexadecimal characters as if they were
in immediately executable form.  So that an object converted to its ASCII form
using ->ASCI will have the same checksum when SCRC is used on the ASCII string
as it would of had before it was converted using the BYTES command.  As in the
ASCI-> program, spaces and newline carriage characters are ignored.



                PEEK

Speed is still an essential attribute of this dual functioning PEEK.  Only the
variable length version will slow slightly when large result strings hundreds
of characters long are returned.  The routine is smart enough to know which of
the PEEKs to implement based on the arguments it's given.  When string results
are preferred, level two should contain a binary integer that's the address to
be peeked, while level one should be a real number representing the length of
the result string.


                POKE

Complimenting PEEK is this dual functioning variable length POKE scheme which
will accept either a string of hexadecimal characters, or a binary integer for
the level two argument that represents the data to be poked.  Level one should
be a binary integer that is the address to poke.  It is important to note that
when the level two argument is a binary integer, the wordsize of that specific
integer will be used to determine to determine the number of nibbles to poke,
and is in no way dependent upon the current wordsize returned by RCWS.



                OUT->

Multifunctioning OUT-> encompasses several of the objects on which OBJ-> will
not work.  ALG->, and PRG-> are analogous to LIST->, only they are intended to
function on algebraics and programs rather than lists; OUT-> functions on all
three of these.  XLIB-> has also been included here; it decomposes visible and
hidden XLIBs into their library and command numbers.  ARR-> was also included
here; it functions identically to ARRY->, but will work on an array of any type
including strings, algebraics, lists, etc.


                ->ALG

Be careful with this one; the stack arguments must be in strict RPN order.  As
before, ->ALG is analogous to ->LIST, only the result is an algebraic, rather
than a list.


                ->ARR

This is my version of ->ARRY; it will build an array of any kind providing all
stack arguments are of the same type. (i.e. strings, reals, algebraics, etc.)
It functions identically to ->ARRY, except that real and complex numbers can't
be mixed.  Level one can be either a real number, a list containing a real, or
a list containing two reals.


                ->DIR

Builds a directory from the stack on the stack.  Level one must contain a real
which is the total number of variables that the directory is to contain, level
two a global name, and level three the contents of that global name.  Because
the entire process utilizes dynamic RAM, it is relatively fast for moderately
sized directories, but slows substantially on very large ones.



                ->PRG

Functions identically to ->LIST, only the result is a program, and not a list.


                ->XLIB

Builds an XLIB from two stack arguments.  Level two can be either a real number
or a binary integer that's the number of the library to which the XLIB belongs.
Level one must be the same argument type as level two and should be the command
number of the desired XLIB.


                RCLDR

Recalls the current directory to the stack in exploded format, after which the
->DIR scheme could be used to pack the stack results back up into a directory.


                RCLIB

This multifunctional routine is to a library what RCL is to a directory.  RCLIB
will recall a library as a fully operational directory.  All that is necessary
to do is to put either the library's name or (real) number in level one.  Again
this is slowed greatly on very large libraries.  RCLIB will work on any library
including ROM (i.e. 2, 240, 1792).  Finally, the contents of any library's XLIB
can be recalled to the stack; simply put the appropriate XLIB in level one, and
the result will be comparable to using RCL on variable stored in a directory.



O  /
 \/
 /\ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
O  \


%%HP: T(1)A(D)F(.);
"04B201611060841434B4944560EB40EF0000000E5F00C00008EB4E00D9D20119
20EB40090770B21308EB4F00D9D2088130F128039916B9F06CCC804E76132230
4E7614525639150493262B1614932651B50B21308EB4010D9D20FA450881303C
37052330AD2A1A2170D9D2029E20EB43108A126CB91629E20EB4F00B21309427
043370D6450B21308EB4110D9D20FA450881303C37052330AD2A1A2170D9D202
9E20EB43108A126CB91629E20EB4F00B2130942704337095450B21308EB4210D
9D20FA450881303C37052330AD2A1A2170D9D2029E20EB43108A126CB91629E2
0EB4F00B2130942704337054450B21308EB4310D9D207E1263991629E20EB421
0112263991629E20EB41102D1263991629E20EB4010B21308EB4410D9D205D55
0D0040C1C16CAF06FEF30083162A170E342405E70D9D2088130F1280399169EB
5088130CCC804E761322304E7614525639150493262B16149326B21304B25639
15051B503223099E70EE170D9D20AD2A18DA16D9D209AF168DA1667E7075660B
213029E20EB4310EF116FED30F6E30D2E300831635316E9330FED30CA130B213
05E17062726F6E30FED30954506AE42B2130CCD20CC0008F146608FB9760D814
7C2134168174147C4C21C413717706D2305D7CD14B31A0962A43102962143114
9EED13103B6A4A531909E61515006910B6A31509E6D330AA0A1500180E71C1CD
56A183DB14418434CCD20144071361448D341508F2D7608DB8F018EB4D00D9D2
05AA812BF819FF30D9D20AEC81881309C080A2170650115B826A21706501129E
20EB4410B2130B2040D9D20F4180A2170650118813029E20EB4410B213058040
D9D2099E70B3A1661050B2130B21308EB4C00D9D20E1A81D9D20FEF30A5D8012
681DA916FBD812A170E3424881303E28059230FED30EF116A36812FA308C170F
BD81B2130B21308EB4B00D9D20FDE8199040D9D20AEC8132230AEC813223005E
70B2130ECD46D9D201D3F405E70B2130B21308EB4A00D9D2043C8154450B2130
8EB4900D9D20ECE819FF30D9D20AEC818A816D9D2041E8091870B2130F6E30C4
1302C23038D30A21702CC81FEF3032230BD3708131605391A2170D9D209AF168
DA1667E7075660B2130122703F21653026A21702BC819EB504B2563915051B50
3223012270FED30300405A3705D550D0040C1C162C23056316FED30954506AE4
2B2130B21308EB4800D9D205AA81D9D202BF819FF30DEE3212040D9D209BC260
3FD16B436B2130FEF302BC81B2130AD3911E136353369B191C41302C230FED30
38D30A21702CC81CCD20F71008F146608FB97601001438FC1830DB10A3441000
CBC7C7C3174147137143135104118CE45506143130D814211C8A2018F2D7608D
7BC818F91030184136E9C35908D066501740757B8FC455011B5F013706DB10B8
4A8F8DA604ED136109135348E92014517411B13418413614517411C14517411A
145D71B97507142130142130174CF4F08F878301455DE118D707CF4331341841
4213606D81308F91030184D9136E91648FC07605AC8F2D760118C3DAC6C6C213
3CA1311191458D94150B21308EB4700D9D2043C81D6450B21308EB4600D9D20E
CE8171040D9D20BCB73122702C230D1730C0726433709A53092591B213012040
379C1F3040379C194040379C158040D9D20CCC80FBD8132230FBD8132230B213
0B21308EB4500D9D2008A81D9D202BF818AB46D9D2030A50322305D550226500
8316C1C16322308A81668F0129E20EB4510B4826B2130ECD46D9D2030A50B213
0FEF302BC81B21302C23061650CCD20130008FD5F30068FB9760147134169131
078FC07608D3415044230B21308EB4400D9D20ECE81D5040D9D2075660CCD20A
4000132100147134164146818FA580D0164D2156113615211341501201101321
42164808CB21309FF30D9D202BF814CD46D9D20AEC81FD5502C230F6E30C1C16
5923030A5059230CCD20A50008FD5F30068FB976014713416913107CED5AE015
B03103A6A31939EA903170A6A148161170CD56D8D34150B2130B2130B21308EB
4300D9D20FDE81ECD46D9D2030A50CCD20570008F146608FB976014713416A15
67AF51801564130152780DF91052160BF4B4651F80CF0D40E910BDBF41605FE1
32E4248FC2245142164808CB2130B21308EB4200D9D20ECE81D0040D9D208813
0636508A81644230CCD206E0008F146608FB9760D8143131179D0100CDD014B3
1A0962E631029625631149EE913103B6A4D631909E6466510B6A31509E64530A
A0A7650D230F0EF2D7331801D0CF480CA68FF118F61087C20100171CD508238F
F2245142164808C8F2D7608DB8F01101FC1180EF6121FE0EF21110EFE0132230
63650FBD81ED2A2EF9A2B2130B21308EB4100D9D20ECE81D0040D9D205D55022
65008316C1C16322308A816852301114048735A2170D9D20881307104038D30A
217068F0166F6088130616507104038D30A217068F0130040C9B26AD2A1B3A16
75660B213029E20EB4510B9F06B2130B21308EB4000D9D205AA81D9D20701404
873508316CB916D9D20D9F8161DC138E51FEF30D9D200CA30E0F06B2130B2130
32230A2170D9D20AD2A18DA16D9D20FD55035040C1C1612040CCD20720008F14
6608FB9760CCD81431301691746E50B2130D9D208813020950FD5502C230F6E3
0C1C1632230CCD20C50008F146608FB9760CCD8143130169174143131AE015B0
3103A6A31939EA903170A6A148161170CD56D8D34150B2130B9F06B2130B2130
B2130E4A2037000C9EFF1DDFFF8CFF6EBFFEBAFF5E9FFD49FFD29FFB17FFB06F
FBE5FFF85FFA15FFC64FF360FFE70FF0D0FF331FF691FF9F1FF442FFC63FFE4A
2006100000000000000000640006B00000000000000000000000000000000000
000000000000000000000005C000403534253420040355454B430040055454B4
4004005F4B45450040F45545D860040D814C47470040D814252580040D844942
590040D8052574A0050D8143534940005014353494D810050D885C49424B0050
2534C44425C00502534C49424D00B400014000AC0002C000AB0002B000AA0002
A000A900029000A800046000A500005000582C57AF"